QRZ! Ham Radio 4/QRZ Ham Radio Callsign Database - Volume 4.iso/digests/tcp/940105.txt

Internet Message Format | 1994-11-13 | 19KB

Date: Tue, 31 May 94 04:30:02 PDT
From: Advanced Amateur Radio Networking Group <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: TCP-Group Digest V94 #105
To: tcp-group-digest


TCP-Group Digest            Tue, 31 May 94       Volume 94 : Issue  105

Today's Topics:
                  Digital Communitations? ... When??
                          Gracilis (2 msgs)
                             Mail failure
                      More RSPF Help needed.....
                 nos-bbs mail address hosed? (2 msgs)

Send Replies or notes for publication to: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Tue, 31 May 94 09:30:04 UTC
From: [e-mail]
Subject: Digital Communitations? ... When??
To: [e-mail]

I read a lot of time, papers, RFC, about "Packet Radio" and something the
author says "digital communication" when i think this is a wrong sentence.

We do (the om's) "Packet Radio". This kind of communication is analog not
digital so we use a modem ...

Am i wrong about this?? Why does a lot of people say "Digical Communication" when refers the "Packet RAdio"??


 Saludos de Curro eb3aod

e-mail : [e-mail]
AX25 : [e-mail]
"Data Highway" : In my Dreamland ...

------------------------------

Date: Mon, 30 May 1994 12:03:30 -0500 (CDT)
From: [e-mail] (Steve Sampson)
Subject: Gracilis
To: [e-mail]

The Gracilis equipment is well designed and simple to operate with the
given software.  Where I would caution anyone is that they not be mere
operators.  These cards require configuration, and sooner or later you
will want to upgrade your NOS and port the Gracilis drivers to it.  In
this case you are on your own.  There is no user group to share
experiances.  I purchased a packetwin when they first came out.  It was
a good card but after a couple years of fighting my NOS blowing up I
decided to get a 9600 KISS modem.  The KISS part of NOS works better
than the Gracilis drivers (or they did back then).  I don't know what
Gracilis is shipping for drivers today, but it's probably the same code
as before, and requires NOS.  I've since graduated from NOS since the
program takes over the whole PC, to Unix which interfaces to KISS much
better than low level interrupts from an SIO chip (a driver which I
couldn't write, and no one else has).

Gracilis cards would seem to be a waste at 9600, but better suited to
the 56k radio modem and a dedicated PC.

The packetten on the other hand is another quality hardware device that
incorporates NOS on a card. This is probably the highest tech device
there is in Ham radio.  It works.  I hear there is a plug in card for
the PC but I haven't seen it in ads or my mailbox.  As a past owner of
their equipment I can say that support is not one of the areas they
feel responsible for.  Not even a newsletter now and then.  If you
look at their prices, see that they're high, and assume you will get
a lot of support, you will be wrong.

As you look back in the ARRL Computer Conference papers you will see a
lot of fancy hardware proposed and designed.  All of it is vaporware
and unavailable.  Gracilis is the only company that seems to be doing
anything in hardware in the United States that can move a product from
design to production.
--
Steve

------------------------------

Date: Mon, 30 May 1994 16:28:59 -0500 (CDT)
From: [e-mail] (Steve Sampson)
Subject: Gracilis
To: [e-mail] (Brandon S. Allbery)

>
> Dunno where you've been, buit there are currently Linux drivers for SCC cards,
> the Ottawa PI2 card, and I'm working on PackeTwin drivers.
>

Where are they available for FTP?  Thanks.

--
Steve

------------------------------

Date: 30 May 1994 09:24:09 EST
From: "POSTMASTER" <[e-mail]>
Subject: Mail failure
To: [e-mail]

Date: Sat, 28 May 94 10:41:37 CDT
From: [e-mail] (System Administrator)
Subject: Gracillis
To: [e-mail]

I have been looking into buying Gracillis for 9600 baud packet. Has
anyone ever tried it..and if so, how is it on TCP/IP?
Also, I'd rather not spend $1,000 for Gracillis new..by chance does
anyone out there have a used one setup they wanna get rid of?

Thanks,
Greg Kaiser - N9TOL

------------------------------

Date: 29 May 1994 09:04:09 EST
From: "POSTMASTER" <[e-mail]>
Subject: Mail failure
To: [e-mail]

Date: Sat, 28 May 94 04:56:05 CST
From: Jack Snodgrass                    <[e-mail]>
Subject: More RSPF Help needed.....
To: tcp-group mailling list             <[e-mail]>

    We've been tearing out my hair trying to figure out how to link 2 RSPF
routers that use an IP Router to communicate.  It seems like RSPF should
work and NOT require that every station in the network Run RSPF, but we
just can't figure out how to make it work.

    We've got:

    --------            --------            --------
     kf5mg   <---440---> wb5tey <---144--->   k5rw
    --------            --------            --------

    kf5mg and k5rw are running RSPF. When either one sends out it's RSPF
broadcast, the other station can't hear it because they're on separate
networks. Is there an easy way to fix this?

    We've set up and AXIP link between the two RSPF routers and set up the
routes between k5rw and kf5mg to use wb5tey.  Now they can hear each others
RSPF broadcast, but the RSPF added routes are screwed up.  All of k5rw's
RSPF added routes on kf5mg show that they route through k5rw on 440 instead
of wb5tey.  All of kf5mg's RSPF added routes on k5rw show that they route
through kf5mg on 144 instead of wb5tey.  I'm guessing that the reason the
routes are screwed up is that RSPF assumes that since it can 'hear' the
station direct ( because of the axip link ) the RSPF added routes assume
that they go direct to the remote system and don't take into account any
pre-existing routes set up between the two RSPF routers.

    Next, we set up an ENCAP link in hopes that if the AXIP link was run
over the ENCAP link the RSPF added links would use the ENCAP link routes.
That didn't work either. The AXIP stuff goes over the ENCAP route, but
the RSPF added routes still ignore the IP router that's in between the two
RSPF routers.

    Someone is probably going to suggest that wb5tey ( in our example ) run
RSPF. Yes... that will work, but I want/need to figure out this problem.
Once we get this working, we'll add RSPF to both of our Internet Gateways.
There's no way to get the network routers between the two gateways to run
RSPF.

    Anyway.... either there is something basic that I'm missing or RSPF is
really un-usable in a standard network and I can't see how one can really
be using it. Any info/help/suggestions ( preferably working ) would be
appreciated. Thanks.

73's  de  Jack  -  kf5mg
Internet        -  [e-mail]            -  44.28.0.14
AX25net         -  kf5mg@kf5mg.#dfw.tx.usa.noam    -  home [phone]
Dialup          -  [e-mail]              -  work (looking  for)
==============================================================================
=
===           Buffalo's new area code.... 044.... "Deal with it"            ==
=
==============================================================================
=

------------------------------

Date: Sat, 28 May 1994 16:28:01 -0400
From: [e-mail]
Subject: More RSPF Help needed.....
To: [e-mail]

Jack,

>    We've got:
>
>    --------            --------            --------
>     kf5mg   <---440---> wb5tey <---144--->   k5rw
>    --------            --------            --------
>
>    kf5mg and k5rw are running RSPF. When either one sends out it's RSPF
>broadcast, the other station can't hear it because they're on separate
>networks. Is there an easy way to fix this?

Not an easy way...

This would have been solved fairly easily had RSPF2.2 been implemented.
RSPF2.2 is a spec that makes clear that "normal" IP rules of "subnets"
do NOT apply, and therefore you can create adjacencies using any kind
of lower-layer (subnetwork in the OSIRM sense) connection and RSPF will
use them if appropriate.  But the code in NOS does not override IP's
routing function, and treats RSPF node groups as IP subnets, which
they ain't.  I don't know what hackery has been done recently to allow
faking things, but it's all half-way.

Note that RSPF was designed to run on routers, but not be needed on
end stations.  Your example is of course the opposite, and tries to
use intellgent end systems to get past a lack of intelligent routers.
Perfectly sensible but since I don't personally _use_ any of the RSPF
variants currently implemented, I can't tell you what works.

If somebody would take the 2.2 spec and really implement it... Naaah,
we're hams.  Why do it right when a quick and dirty early hack is
available?  Why should routing be different from the "202" modems?  :-(

(sig)>           Buffalo's new area code.... 044.... "Deal with it"
I must be missing something...
    fred k1io

------------------------------

Date: Sat, 28 May 94 11:21:03 CST
From: [e-mail] (Fco. J. Chavarria -POLITEC)
To: [e-mail]

unsub [e-mail]

------------------------------

End of TCP-Group Digest V94 #103
******************************


------------------------------------------------------------------------------

------------------------------

Date: Sun, 29 May 94 05:48:00 -0000
From: [e-mail] (Mike Bilow)
Subject: More RSPF Help needed.....
To: [e-mail]

Cc: [e-mail]

 JS>     We've been tearing out my hair trying to figure out
 JS> how to link 2 RSPF
 JS> routers that use an IP Router to communicate.  It seems like RSPF should
 JS> work and NOT require that every station in the network Run RSPF, but we
 JS> just can't figure out how to make it work.

I understand your problem exactly.  There really are no easy ways to do what
your want, but it should be possible.  However, it is an involved thing and I
don't want to sit here typing away nonsense before I think it through.  A lot
of these kinds of problems are a result of features in the formal RSPF spec
remaining unimplemented.

RSPF was intended to function as an interior routing protocol within the
autonomous system which is Amprnet.  The expectation was that all routers woul
d
be running the routing protocol.  This is not an unreasonable expectation, and
it applies pretty much equally to any other routing protocol besides RSPF.  En
d
nodes which have no routing responsibility are not usually expected to run
RSPF, but that is a very different thing.

-- Mike

------------------------------

Date: Mon, 30 May 1994 09:05:19 CET
From: "Jack Stiekema" <[e-mail]>
Subject: TCP-Group Digest V94 #103
To: Advanced Amateur Radio Networking Group <[e-mail]>

>>    We've been tearing out my hair trying to figure out how to link 2 RSPF
>>routers that use an IP Router to communicate.  It seems like RSPF should

Maybe a silly question,
but what is RSPF?


Kind regards,
Jack Stiekema
Product Manager Connectivity
+----------------------------------------------------+
| Victron bv   POB 31   9700 AA Groningen   Holland  |
|   Phone: [phone]   Fax: [phone]        |
|   Email: [e-mail] Internet: 193.78.6.6      |
|   Home:  [phone]  [e-mail]    |
+----------------------------------------------------+

------------------------------

Date: Mon, 30 May 1994 10:43:38 MET
From: [e-mail]
Subject: unsub
To: [e-mail]

unsub [e-mail] tcp-group

------------------------------

End of TCP-Group Digest V94 #104
******************************


------------------------------------------------------------------------------

------------------------------

Date: Mon, 30 May 94 08:23:00 -0000
From: [e-mail] (Mike Bilow)
Subject: More RSPF Help needed.....
To: [e-mail]

Cc: [e-mail]

 JS> On a different subject.... I think that you were
 JS> talking about putting together
 JS> a packet driver that ran in an OS/2 dos box and would
 JS> talk to another packet
 JS> driver in a second OS/2 Dos box. Was that you?

I was actually talking about making a shim for G8BPQ that would allow BPQCODE
to run in a DOS window and communicate with separate processes running in their
own DOS windows.  This would allow using G8BPQ in connection with OS/2 much the
same way as it is commonly used with DESQview.  However, I was not planning to
implement this as a packet driver.

 JS> How much do you
 JS> know about OS/2 programming? I'm reading up on it.

A fair amount.  There are some other people around, particularly Walt Corey,
[e-mail], who could also be of help.

 JS> One
 JS> question I have and
 JS> can't find an answer to is 'How can a DOS Box get
 JS> access to OS/2 pipes and
 JS> semaphores?

The proper architecture -- and I'm not saying it is the only way to do it -- is
to write a Virtual Device Driver that presents some convenient API to the DOS
program.  The VDD would be able to manage OS/2 IPC resources, including
semaphores, pipes, queues, and even shared memory.  You have to be especially
careful with pipes, since they can be non-local (network) resources.

 JS> Also... what OS/2 'features' can the DOS
 JS> Box utilize? I'm thinking
 JS> that you could write a OS/2 packet server that runs in
 JS> an OS/2 session. Then
 JS> your DOS Box Packet drivers would talk to this system
 JS> using pipes or shared
 JS> memory. The OS/2 Packet Server would handle getting the
 JS> data to the other DOS
 JS> Box. Anyway.... can't make any progress on this till I
 JS> figure out how to give
 JS> a DOS program accesses to OS/2 stuff.

The packet driver architecture is DOS-specific, and you cannot make such a
thing run as an OS/2 session.  What you can do, if you are committed to the
packet driver API for some reason, is write a VDD that presents the packet
driver API to a DOS process, and translates or emulates that API to something
else that is OS/2 compatible, preferably NDIS.  This kind of thing probably
exists, but I don't know about it right off.

It would also be possible to write the VDD such that different DOS processes
could be given the illusion of exclusive access to their own packet driver,
provided that some acceptable means for sorting out which process owns which
frames can be developed.

 JS> Lastly.... If you know much about OS/2 programming....
 JS> any idea how to talk to
 JS> the NDIS drivers from a 'C' program? Thanks.

This depends upon the exact implementation of your NDIS layer.  The usual
method is to be given a device driver with the *.OS2 naming convention, and
a*.NIF text file which provides the necessary information to access the driver,
such as device name.

It is actually extremely rare that an applications developer would want to
access the NDIS driver directly, since you are usually going through LAPS ("LAM
Adapter Protocol Support") or NTS/2 ("Network Transport Services/2") or
whatever it is called now to get to the network.  If you are implementing the
protocol stack yourself, the best way is to write a reentrant DLL and export
whatever API you need.  At minimum, it would be prudent to go through LAPS,
which does most of this low-level work for you.  Also, LAPS is the only way to
guarantee properly shared use of the LAN between different protocol stacks.

Maybe if you gave me a better idea of what you were trying to do, I could be
more informative.

-- Mike

------------------------------

Date: Tue, 31 May 94 04:16:00 -0000
From: [e-mail] (Mike Bilow)
Subject: nos-bbs mail address hosed?
To: [e-mail]

Cc: [e-mail]

 LN> Using a needless MX adds to innefficiency - you have to do the A record
 LN> lookup anyway to deliver to the machine.

If there is no MX record at all, then DNS queries will be sent for MX
of"hydra.carleton.ca", "*.carleton.ca", and "*.ca" before a request for an A
record is made.  Since all three queries will fail to return any resource
records, they must all be responded to by an authoritative name server for
their respective domains, as negative responses cannot be cached.  If there is
an MX record for "hydra.carleton.ca", then the process will move immediately to
obtaining the A record, and at least two queries will be avoided.

Also, if the NS records needed to make the MX queries are not known, then
additonal queries will be generated to get them.  With a proper MX record in
this case, all of the queries will be to the same name server, and positive
responses can be cached.

-- Mike

------------------------------

Date: Mon, 30 May 1994 23:58:16 -0700 (PDT)
From: Lyndon Nerenberg <[e-mail]>
Subject: nos-bbs mail address hosed?
To: Mike Bilow <[e-mail]>

> If there is no MX record at all, then DNS queries will be sent for MX
> of"hydra.carleton.ca", "*.carleton.ca", and "*.ca" before a request for an A
> record is made.

Is this the case? We're crossing boundaries between DNS and MTA
implementation here, but it seems to me that any MTA that would query
*.ca MX's when looking for hydra.carleton.ca is broken. A reasonable
search tree would be:

    * MX for hydra.carleton.ca
    * A for hydra.carleton.ca
    * MX for *.carleton.ca
    * MX for *.ca

and I would disagree with the latter as a matter of principal, since
you're *very* unlikely to find a wildcard MX for a top level domain.
Much of this depends on how flexible (smart?) your resolver routines are.

> Also, if the NS records needed to make the MX queries are not known, then
> additonal queries will be generated to get them.  With a proper MX record in
> this case, all of the queries will be to the same name server, and positive
> responses can be cached.

True, but your MTA could do the initial DNS query asking for everything
about hydra.carleton.ca and get back both the MX and A records (if they
both existed) in a single response (modulo UDP datagram size limits).

(Sorry to pick on you, Barry :-)

--lyndon

------------------------------

End of TCP-Group Digest V94 #105
******************************